1. Field of the Invention
The invention relates to MIDlet suites and Open Services Gateway Initiative. In particular, the invention relates to a novel and improved way of deploying MIDlet suites in an Open Services Gateway Initiative environment.
2. Description of the Related Art
Today more and more various terminal devices and embedded devices include a Java programming language platform to allow running of Java applications. One of these Java platforms is Java 2 Platform, Micro Edition (J2ME). J2ME is targeted particularly at embedded systems with limited resources, such as mobile phones, pagers, personal digital assistants, smart cards and set-top boxes. Due to differences in capabilities of devices implementing J2ME, J2ME has been segmented via configurations and profiles. A configuration-profile pair defines a minimum set of application programming interfaces or APIs a device must support. Typically, this set can be extended with additional optional libraries. Two of the configurations included in J2ME are Connected, Limited Device Configuration (CLDC) and Connected Device Configuration (CDC).
CLDC is targeted at devices with limited resources, such as mid- and low-end mobile phones, for example. CLDC defines a virtual machine and a set of libraries which are scaled down compared to those specified in the Java Language Specification. Mobile Information Device Profile (MIDP) is a profile specified especially for the CLDC. MIDP defines a simple model for application programming, including an application model, a user interface (e.g. textboxes, forms) and networking.
CDC is targeted at relatively powerful devices which are less resource limited than those targeted by CLDC, such as e.g. smart phones, communicators and personal digital assistants. CDC defines a virtual machine that is fully compliant with the Java Language Specification. CDC is usually accompanied by a Foundation Profile (FP) which extends the basic set of libraries of the CDC for e.g. input/output, networking and security. However, FP does not specify an application model. The application model and user interface libraries are disclosed by a Personal Profile (PP).
A Java application that conforms to MIDP and CLDC is called a MIDlet. MIDlets are typically targeted at devices that provide some level of network connectivity. The devices that will run MIDlets typically also have several common attributes: limited screen size, memory and processing power. As described above, MIDP and CLDC are designed to address these constraints.
MIDlets are often packaged and distributed as MIDlet Suites. A MIDlet Suite is a set of one or more MIDlets plus resource files that may be required by these MIDlets. The MIDlet Suite is typically deployed as a Java Archive (JAR) file. Furthermore, a Java Application Descriptor (JAD) file may be associated with the JAR file. The JAR file comprises one or more Java class files, and a manifest file describing the contents of the JAR file. The JAR file may further comprise resources, such as e.g. images and application data. The manifest file included in the JAR file is typically a text file containing various attributes related to the MIDlet Suite, such as a name of the MIDlet Suite, a version number of the MIDlet Suite, a vendor name of the MIDlet Suite, a J2ME Profile required by the MIDlet Suite, and a J2ME Configuration required by the MIDlet Suite. The JAD file is typically a text file containing administrative information about the MIDlet Suite and the JAR file the MIDlet suite is packed into, such as a name, JAR file size, version number, vendor information and a Uniform Resource Locator (URL) address of the JAR file. An object of the JAD file is to facilitate getting information about the JAR file: since typically the JAD file is significantly smaller than the JAR file which comprises the entire MIDlet suite, it is faster to download only the JAD file rather than the JAR file.
In recent years MIDP in combination with CLDC has become extremely popular. In mobile phones, it is today the dominant Java platform for third party applications. In other words, there is a vast amount of MIDlets already developed, and more are being developed.
Yet the platform consisting of MIDP and CLDC has also met more and more criticism for not being rich and attractive enough, and for remaining behind the standard Java platform in terms of APIs and applied virtual machine technologies.
One of proposed solutions to the above criticism is called Open Service Gateway Initiative (OSGi) which provides a richer application framework than the platform consisting of MIDP and CLDC. E.g. Java Specification Request (JSR) 232 proposes using OSGi as an underlying application framework for mobile devices. OSGi is a generic, service centric execution environment. It specifies a generic framework and a core set of service interfaces that enable delivery of multiple value added service implementations, potentially from different vendors. OSGi provides a general-purpose, secure and managed Java framework that supports the deployment of extensible and downloadable service applications known as bundles.
OSGi-compliant devices can download and install OSGi bundles, and remove them when they are no longer required. Bundles can register a number of services that can be shared with other bundles under control of OSGi. OSGi can run on top of CDC and FP. In OSGi several bundles can be run simultaneously on a single virtual machine, whereas in previous Java frameworks only one Java application may be run on one virtual machine. As opposed to the platform consisting of MIDP and CLDC, with OSGi there is no need to load and execute the virtual machine as many times as the number of running Java applications. Thus memory consumption is reduced.
However, OSGi does not support managing or executing MIDlets. Yet such support is imperative due to the vast amount of MIDlets developed.
An attempt at enabling execution of MIDlet suites on OSGi is provided by a corporation called Prosyst (http://www.prosyst.com). The solution by Prosyst is a bundle called MIDPLauncher that, when started, shows the installed MIDlet suites on a graphical user interface and registers a service that can be used by other bundles to install, start, stop uninstall or update a MIDlet suite.
However, there is a significant drawback to the above solution by Prosyst: it requires extensive and cumbersome user interaction. Once the MIDPLauncher is stopped, the MIDlet suites become completely unavailable to the user and the OSGi environment. Therefore, when the user wants to execute a MIDlet and the MIDPLauncher is not already running, the user is first required to launch the MIDPLauncher in order to enable execution of the MIDlet. Likewise, if the MIDlet suite comprises several MIDlets, the user is required to launch the MIDPLauncher before being able to select a MIDlet to be executed. Furthermore, even while the MIDPLauncher is running, the OSGi environment sees only the MIDPLauncher bundle rather than the separate MIDlet suites.
Therefore, an object of the present invention is to alleviate the problems described above and to introduce a mechanism that allows using deployed MIDlet suites in an Open Services Gateway Initiative environment with no user interaction or at least with significantly less user interaction than with prior art arrangements. A further object of the present invention is to allow starting, stopping and uninstalling the deployed MIDlet suites without requiring a management application or any other application associated with the Open Services Gateway Initiative environment to be running at the same time. Yet a further object of the present invention is to allow executing multiple MIDlets in parallel in the Open Services Gateway Initiative environment.